[Serverless Days Tokyo 2019] 空調設備向けIoTシステムにおけるクラウドランニングコスト

レポートが遅くなりましたが、10/22（火）に開催されたServerless Days Tokyo 2019のセッションレポートです。

登壇者

ダイキン工業株式会社

野原健太

スライド

https://speakerdeck.com/nohara/kong-diao-she-bei-xiang-keiotsisutemuniokerukuraudoranningukosuto

レポート

• ダイキン工業のIoTの取り組み
  • 空調事業を主力とする会社
  • 150カ国以上に事業を展開
  • IoTの取り組み
  • 全世界の空調機をインターネットにつないで、販売、施工などのライフサイクルに対するサービスを提供
• Daikin Global Platform
  • システム規模
  • 想定機器接続台数: 500万台（各機器から毎分データが発生）
  • 想定ユーザー数: 30万人（同時アクセス9万人）
  • 高いスケーラビリティが求められる
  • 無限に発生するデータを扱えるストレージ
  • サーバーレスでやるしかない！
  • すべてNoSQLで実現
• サーバーレス開発
  • サーバーレスはマネージドサービスを適切に使いこなせば、作りたいものは実現できるが、目標ランニングコスト以内で動かすシステムを作ることが難しい。
  • 一般的にサーバーレス化＝コストが下がると言われているが、ある程度の規模で負荷がかかるシステムだと青天井になる可能性がある
  • サーバーレス開発はランニングコストとの闘い
• Daikin Global Platformのシステム構成
  • 空調設備から送られてくるデータをKinesisで受け取りLmabdaで処理して、DynamoDBに格納
  • DynamoDBに格納されたデータをAPI Gateway→Lambdaの構成でユーザーがアプリケーションで取得
  • 全体大半のランニングコストがDynamoDBに書き込む時のWCUのコストとユーザーのアプリケーションから大量に送られてくるリクエストを処理するLambdaのコスト
  • ランニングコストを最適化するには、DynamoDBのデータ構造を最適化するのがポイント
• コストを抑えるためのDynamoDB設計
  • 最初に設計したDynamoDBの設計では、1機器1アイテムとして格納。この設計には問題あり
  • 1アイテムが数十kBあるため、運転データの１項目だけが送られてくるパターンでも、書き込み処理に数十WCUを消費してしまう。
  • 各機器から毎分データが送られてくるため、その度にWCUを消費してしまう
  • 上記の設計を見直して、1機器Nアイテムとして設計
  • 1機器Nアイテムにしたので、１項目だけ送られてきた場合にWCUの消費量を解消
  • ただ、これでも問題あり。。。
  • Nアイテムに分割して保存したため、データ取得の際に数十機器 × Nアイテムで数千アイテムを取り出さなくてはいけなくなり処理時間がかかってしまった＝Lambdaの実行時間に影響
  • さらに上記の設計を見直して、パーティンションキーを建物IDとし、1機器Nアイテムとして保持しソートキーとして機器ID_項目名としてソートキーに機器IDと項目名を両方含めるように変更
  • これによって、建物IDをキーとしてデータをクエリすることでデータを一回のAPI呼び出しで取得することが可能になり、Lambdaの実行時間の短縮につながった。書き込みも項目ごとに書き込めるので、WCUの消費を抑えることが可能
• まとめ
  • DynamoDBのデータ構造はランニングコストを考える上で非常に重要
  • DynamoDBは書き込みの料金が読み込み料金の10倍なので、高頻度でデータを書き込むキーの設計を適切に行う必要がある

まとめ

サーバーレスのランニングコストをどのように削減するかの視点で、DynamoDBのテーブル設計を変更していくというのがとても参考になりました。今回のダイキン工業の事例のようにIoT機器からのデータをKinesisからLambdaで処理してDynamoDBに保存するアーキテクチャはサーバーレスなIoT案件としては一般的になってきました。IoTでは大量のデータがリアルタイムで送られてくるパターンが多くDynamoDBへ高頻度で書き込む必要があるため、ランニングコストを最適化するためのキー設計はとても重要度だと思いました。